home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000042_kalua@cs.indiana.edu _Wed Mar 17 22:39:43 1993.msg < prev    next >
Text File  |  1996-01-31  |  6KB  |  120 lines
  1. Message-Id: <199303180339.AA17498@optima.cs.arizona.edu>
  2. Received: from moose.cs.indiana.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
  3.     id AA17498; Wed, 17 Mar 1993 20:39:00 MST
  4. Received: by moose.cs.indiana.edu
  5.     (5.65c/9.4jsm) id AA04759; Wed, 17 Mar 1993 22:39:43 -0500
  6. Date: Wed, 17 Mar 1993 22:39:43 -0500
  7. From: "Patrick P Kalua" <kalua@cs.indiana.edu>
  8. To: tsql@cs.arizona.edu
  9. Subject: Benchmark correspondence
  10.  
  11.  
  12.  
  13.                        The TSQL Benchmark Draft
  14.                        ************************
  15.  
  16.  
  17.    Our comments and suggestions to Christian's proposal for TASK I of the
  18.    consensus TSQL Benchmark :
  19.  
  20.    1) Restrictions
  21.       ------------
  22.         Since we are still dealing with some aspects of temporal reasoning, the
  23.         restriction "Temporal reasoning is beyond ...." should perhaps be
  24.         re-phrased to "General temporal reasoning ...."
  25.  
  26.         We also feel that the following restrictions are perhaps too strong and
  27.         we should probably relax them abit.
  28.  
  29.             (a) that each relation be used only once in each query
  30.             (b) queries involving aggregation facilities be excluded
  31.  
  32.         For the past few years we have been interacting with a number of
  33.         demographic researchers and most of their questions seem to be centered
  34.         around "events", "event sequences", "waiting times" etc We have also
  35.         looked at a number of clinical databases where the queries involving
  36.         these same parameters seem to dominate. Events and event sequences are
  37.         facts of life and there are a lot of simple queries that we can form
  38.         even on the present schema around these parameters. However all those
  39.         queries involving event sequences would be eliminated with
  40.         restriction (a).
  41.  
  42.         Temporal aggregation may involve :
  43.            - summing attribute values of entity instances over time
  44.            - counting entity instances over time
  45.            - finding max/min/avg of attribute values over time
  46.            - summing time period (spell) length
  47.            - counting events
  48.            - finding max/min/avg of time periods
  49.            - finding moving average of attribute values over time
  50.           
  51.        Some of these operations are very simple and yet very important.
  52.        Aggregation exhibits some important temporal semantics and since we are
  53.        interested more in the semantics of the queries and not efficiency or
  54.        performance, we feel that simple aggregation operations ought to be
  55.        allowed. This would give us a semantically rich initial benchmark.
  56.        **HOWEVER,** we also realize that because of the limited time between
  57.        now and June, we could possibly move the addition of these operations
  58.        to the second iteration of the benchmark (after the workshop). In that
  59.        case, prioritizing the process of lifting the restrictions is something
  60.        we should probably consider and agree upon.
  61.  
  62.    2) The Benchmark Database Schema
  63.       -----------------------------
  64.  
  65.      2.1)  Criteria
  66.  
  67.          We propose adding another criterion :
  68.                " The schema should be natural. That is, it should
  69.                  correspond to a reasonable, though possibly greatly
  70.                  simplified, segment of the real world. This both
  71.                  reduces the need to explain the model and enhances
  72.                  the ability to recognize verball pitfalls in the path
  73.                  to the query instances."
  74.  
  75.       2.2) Proposed Schema
  76.  
  77.         The proposed schema seems simple enough and suitable for the purpose.
  78.         However, we suggest that we add one or two non-temporal (that is,
  79.         time-invariant) attributes to the Emp relation - gender and/or
  80.         birthdate. This would :
  81.  
  82.             (a) potentially add a few more queries to the pool, and
  83.             (b) perhaps more importantly, give us at least one NON-TEMPORAL
  84.                 attribute in the schema.
  85.  
  86.         If we agree to add only one them, our preference would be gender.
  87.         While both of these can be considered to be non-temporal, birthdate
  88.         involves some element of time, albeit user-defined time. Gender would
  89.         automatically divide the data set into two subsets each which would be
  90.         large enough to provide reasonable outputs. We are also influenced by
  91.         our contact with social scientists, among whom gender-related queries
  92.         are common.
  93.  
  94.         It would also be a good idea, possibly at a later stage, to add a
  95.         traditionally multi-valued attribute such as "skills" where the
  96.         following snapshot fd holds :
  97.                       Name --->> Skills
  98.         Our assumption here is, of course, that " a person can have multiple
  99.         skills at a time and the set changes with time". In this schema, the
  100.         assumption for the other attributes (Dept, Salary) is that they are
  101.         single-valued. A person can be in only one dept at a time and will
  102.         earn only one salary at a time. But over time, the person may have
  103.         worked in several departments and may have earned several salaries.
  104.         We call such attributes **"serially multi-valued"** as opposed to
  105.         "Sex" which is traditionally single-valued and "Skills" which is
  106.         traditinally multi-valued.
  107.  
  108.  
  109.  
  110.      We welcome any comments.
  111.  
  112.  
  113.      Patrick P Kalua                       Ed L Robertson
  114.      kalua@cs.indiana.edu                  edrbtsn@cs.indiana.edu
  115.                         Indiana University,
  116.                         Computer Science Dept,
  117.                         Bloomington, IN 47405.
  118.                   
  119.  
  120.